To formulate the standard specifications for the data sync of personal information and enterprise data among a plurality of platforms and networks, the OMA proposes SyncML data sync specifications. The objective of SyncML development is to implement the collaborative work among terminal users, device developers, basic component developers, data providers, so as to make it possible to access data of any network anywhere at any moment by using any terminal device. The typical scenario is the data sync between a mobile device/an application server and a network server. In addition, the SyncML can also be used in the peer-to-peer data sync, such as the data sync between two personal computers (PC).
FIG. 1 is a schematic diagram illustrating the data sync based on the SyncML specifications. After having negotiated parameters in a data sync initialization phase, a client and server send the data that has changed to each other to guarantee the data is synchronized between the two parties.
A Data Synchronization Client (DS Client) generally refers to an intelligent terminal, such as PC software, mobile phone or Personal Digital Assistant (PDA) etc. A Client Database is configured in the device to store the user data, including: an address book, calendar, note, short message, e-mail, etc. The formats of all these data are defined in standard specifications, and the DS Client is able to convert the data into a standard format and send the converted data to a DS Server which processes the data and stores them in its database.
The DS Server may receive a sync message containing sync commands from the DS Client and send a sync message back to the DS Client. The DS Server may be a network server or a PC. A Server Database is configured in the DS Server to store the data of the DS Server.
Data identifiers are stored in both the DS Client and the DS Server. The DS Client uses a Local Unique Identifier (LUID) as the data identifier while the DS Server uses a Global Unique Identifier (GUID) as the data identifier.
FIG. 2 is a schematic diagram illustrating the data storage of a DS Client and a DS Server. As shown in FIG. 2, only the correspondence relationship between various LUIDs and data needs to be maintained in the DS Client, but in the DS Server, not only the correspondence relationship between various GUIDs and data but also the correspondence relationship between various GUIDs and LUIDs needs to be maintained. There are multiple data sync types, as shown in Table 1.
TABLE 1Sync typeDescription informationTwo-way syncA normal sync type in which the client and the server exchange information aboutmodified data in these devices. The client sends the modifications first.Slow syncA form of two-way sync in which all items are compared with each other on afield-by-field basis. In practice, this means that the client sends all its data from adatabase to the server and the server does the sync analysis (field-by-field) for this dataand the data in the server.One-way sync from clientA sync type in which the client sends its modifications to the server but the server doesonlynot send its modifications back to the client.Refresh sync from clientA sync type in which the client sends all its data from a database to the server (i.e.,onlyexports). The server is expected to replace all data in the target database with the datasent by the client.One-way sync fromA sync type in which the client gets all modifications from the server but the client doesserver onlynot send its modifications to the server.Refresh sync from serverA sync type in which the server sends all its data from a database to the client. Theonlyclient is expected to replace all data in the target database with the data sent by theserver.Server Alerted SyncA sync alert type, which provides the means for a server to alert the client to performsynchronization. When the server alerts the client, it also tells the client which type ofsynchronization to initiate.
In addition, the data sync procedure defined in the SyncML specifications usually includes three phases:
1. A sync initialization phase, in which, it is mainly to implement authentication, negotiation of the sync database to be synchronized, negotiation of sync capabilities (including: which data formats and sync types are supported by client and/or server, etc.), and such negotiation procedures may have to be conducted for several times.
2. A sync phase, mainly including: one side of the DS Client and DS Server sending the data that have changed to the other side of the two via an operation command according to the data status modification; and the other side performing the operation command (e.g., an operation command of update, delete, or add), with the data that have changed to update its own data so as to achieve the purpose of the data sync.
3. A sync accomplishment phase, which mainly includes: the DS Client and the DS Server confirming the accomplishment of the sync to each other.
In the prior art, the storage mode of Folder and File has been defined for the data, which simulates the tree structure based on the folders and files in the PC. For the data with hierarchy relationship logically or physically, the data can be presented as a tree structure consisting of at least one node, each node of which may be a folder node (also referred to as a folder item) or an item node (also referred to as a data item). But, it is not possible to sync a specific node with its content or a sub-tree as required in the prior art. Besides, the method for synchronizing the address book by groups is implemented by using the filter technique based on the Group field within the vCard, the defect of which is that the sync protocol is tightly coupled with specific data formats, which is not general for all data formats, so a specific node with its content or a sub-tree in the tree structure may not be synchronized as required.
However, at present, there are a lot of data needed to be synchronized which are stored as a fact of the tree structure with hierarchy relationship logically or physically. For example, some data are organized by folders in a tree structure view which logically or physically exists in a user's mobile phone, such as an address book, categorized short messages and e-mails organized by mailboxes, etc. In addition, a calendar or email with attachments could be considered as organized in a hierarchy manner as well. In accordance with the prior art, the user can only sync the whole database rather than a part of the database. Taking short messages as an example, the user can only sync the whole database of the short message but can not sync only one category of the short message named “bless” and leave another category named “joke” not synchronized this time. With regard to the attachment stored outside of the calendar/email, the attachment can not be synchronized and the hierarchy relationship of the attachment and the calendar or email can not be described in the prior art. Meanwhile, it can not be implemented that one data item exists in two categories. For example, Zhang San belongs to the groups of “colleague group” and “friend group” in the address book at the same time.
To sum up, the existing data sync techniques can not satisfy the actual demands, and especially, can not support the notion of one data item in a hierarchy manner or the data sync of any node level in the hierarchy structure.